Day 1 說過 LLM 是你接過最不守規矩的下游依賴，但前十天我們其實只讓它用訓練時學到的知識回答問題。問它「你們家的退貨政策是什麼」，模型沒有這份專有資料；它可能拒答，也可能生成一個聽起來合理、卻沒有依據的答案。Day 9、10 把成本與流量的邊界立了起來，但沒有替回答補上可核對的來源。

RAG（Retrieval-Augmented Generation）就是對這個問題的工程回答。這篇不教你「五分鐘架好 RAG」，而是先把這個詞拆開：它是什麼、不是什麼、會在哪裡壞掉，因為 Part 3 接下來四天要動工的每一個部件，都掛在今天這張圖上。

RAG 是一個 retrieval pattern，不是 AI 魔法

官方定義一句話：RAG 是讓語言模型處理「它本來不知道的特定或專有資料」的 industry-standard pattern（查核 2026-07，Azure Architecture Center）。做法直白到有點反高潮：在呼叫模型之前，先去搜尋相關資料，把搜到的內容塞進 prompt，讓模型「照著參考資料回答」。

用 backend 的語言說：這是一個「先查再答」的 read path。你以前就寫過：使用者問訂單狀態，你不會叫 API 憑印象回答，你去查資料庫，把查到的資料 render 成回應。RAG 只是把「render 成回應」這一步換成 LLM，讓它把查到的資料組織成自然語言。

類比失真的地方也要先講。查資料庫，查到什麼就是什麼；LLM 拿到參考資料之後仍然可能不照著寫，可能忽略、扭曲，或補上資料裡沒有的內容。所以 RAG 不是把幻覺問題「解決」了，而是把它從「憑空編造」降級成「有參考資料可核對的生成」。這個差距怎麼收斂，是 Day 14（grounding 與 no-answer policy）的主題。

兩條 pipeline：生命週期不同，就該分開設計

RAG 包含兩條生命週期完全不同的 pipeline。

Microsoft 的架構指南與 Seven Failure Points 論文都把問題拆到 indexing、retrieval、augmentation 與 generation 等階段。兩份來源的術語與圖面不完全相同，但都主張把檢索前的離線工作與線上查詢路徑分開觀測、評估與除錯。

來源查核 2026-07：Microsoft 架構指南、Seven Failure Points 論文。

Indexing pipeline 是離線/非同步路徑，觸發時機是首次匯入、資料異動、或排程更新：把文件切塊（chunk）、補上 metadata（enrich）、用 embedding model 算成向量（embed）、寫進 search index（persist）。

Query pipeline 是線上路徑，在每個需要檢索增強的查詢執行（不是應用的每個 request，health check、不需要 RAG 的對話輪都不走它）：先把問題用同一顆 embedding model 算成查詢向量（hybrid search 需要文字與向量兩路並行，缺一不可）、拿去檢索、取 top-K 個 chunks、組進 prompt、呼叫 LLM 生成。它直接吃你的 latency budget 與 token budget。

注意線上路徑的第一步：query embedding 是一次線上的上游呼叫，有自己的延遲、失敗面與帳單。本系列選擇由應用自己呼叫 embeddings（而非 AI Search 的 integrated vectorization），所以「檢索壞了」的除錯要先分清：是 embedding 呼叫壞了，還是 search 壞了。

為什麼堅持分開講？因為兩條管線的一切都不同：

把 RAG 當「一個功能」的隱形代價就在這裡：線上答錯了，你不知道該去查哪條管線。答案根本沒進 index？切塊切壞了？還是檢索排序把它排掉了？分開設計，才能分開除錯。這也是為什麼 Part 3 的節奏是 Day 12 做 indexing、Day 13 做 retrieval、Day 14 才把 query pipeline 串起來。

為什麼不是 fine-tuning？

每次講 RAG 都有人問：為什麼不直接把公司資料 fine-tune 進模型？

這題有官方答案，而且 Microsoft 與 OpenAI 的說法一致。OpenAI 把模型優化拆成兩軸（查核 2026-07，OpenAI optimizing accuracy）：

• context optimization：模型缺知識（沒學過、過期了、專有資料），用 RAG 解。
• LLM optimization：模型行為不對（格式不穩、語氣不對、推理方式不對），用 fine-tuning 或 prompt engineering 解。

一句話版本：知識問題找 RAG，行為問題找 fine-tuning。

Microsoft 的 fine-tuning 文件補了細節：fine-tuning 要的是「數百到數千筆 task-specific 範例」，最擅長的是行為調整（風格、輸出格式、工具使用）；對於穩定不變的領域資料，它也能做 domain specialization（查核 2026-07，來源）。

所以「知識 vs 行為」是第一道診斷軸，不是絕對的能力邊界。兩者也能疊加（fine-tune 教模型更會用檢索到的 context）。

用第一道軸診斷我們的題目：回答退貨政策是知識問題，而且是會變的知識問題。資料會變（fine-tune 完政策改了就要重訓）、需要存取控制（fine-tune 進模型的知識沒有 per-user 權限這回事）、需要說得出根據（RAG 可以引用來源，模型權重不行）。三個理由每一個都指向 RAG。

反方向的證據也存在：OpenAI 文件記錄過一個冰島語文法修正的案例，在已經 fine-tune 過的模型上加 RAG，準確率反而掉了四個 BLEU 點，因為那是行為問題，塞參考資料只是干擾（同上來源）。RAG 不是萬靈丹，是知識問題的解。

RAG 會在哪裡壞？七個失敗點

RAG 最被低估的事實：retrieval 是上游瓶頸。Microsoft 的 RAG 評估文件直說：正確的 context 沒被撈進 prompt，模型再強也很難給出扣著 corpus 的好答案（查核 2026-07，來源）。

入門版分類用 OpenAI 的兩分法就夠：retrieval failures（給錯 context，或塞太多無關 context 把真資訊淹掉）vs LLM failures（context 對了但模型用錯）。要細一點，工程界最常引用的是 Seven Failure Points（Barnett et al., CAIN 2024，arXiv:2401.05856），七個失敗點可以直接標在今天那張圖上：

• 檢索側：FP1 Missing Content（corpus 裡根本沒有答案，是 indexing 的問題）、FP2 Missed Top Ranked（答案在 index 裡但沒排進 top-K）、FP3 Not in Context（撈到了但組 context 時被擠掉）。
• 生成側：FP4 Not Extracted（在 context 裡但模型沒抽出來）、FP5 Wrong Format（不照要求的格式）、FP6 Incorrect Specificity（答太粗或太細）、FP7 Incomplete（沒錯但漏答）。

注意 FP1 到 FP3 全部發生在 LLM 拿到 prompt 之前。這就是「RAG 工程其實是 search 工程」的證據。也注意 FP1 的正確行為是說不知道：corpus 裡沒有的東西，系統誠實回答「查無資料」是 feature，硬答是 bug。

這條會在 Day 14 變成一個明確的 API 合約決策（no-answer policy）。lab 裡已經有一支 feature 檔幫它占位，但目前它只驗「endpoint 還沒實作回 501」；真正把 no-answer 變成可執行的合約 scenario，是 Day 14 的工作。

忍喵：「七個失敗點有三個在模型開口之前就發生了。答錯就怪 LLM 太笨、想換更大的模型之前，先去看檢索到底撈了什麼給它。」

那篇論文還有兩句工程師會心一笑的結論：RAG 系統的驗證只能在營運中做；robustness 是演化出來的，不是一開始設計出來的。翻譯成本系列的語言：Day 8 的 prompt 版本追蹤、Day 9 的 usage 記帳、correlation id 一路串到底。這些是地基，但還不是 RAG 的可觀測性：檢索了幾筆、選了哪些 chunk、各拿幾分、每段花多久，這些 per-stage log 目前都還不存在，Day 13–14 實作時要把它們當合約的一部分補上。可觀測性不是 RAG 的加分項，是它能被修好的前提。

Azure 對應：AI Search 與 embeddings，以及一個刻意的選擇

把圖上的格子換成 Azure 服務：檢索引擎是 Azure AI Search，向量化用 Azure OpenAI embeddings（現行第三代選擇是 text-embedding-3-large / 3-small；較舊的 ada-002 仍在清單上，查核 2026-07，模型清單）。兩個對 backend 工程師重要的細節。

第一，embeddings 不走 Responses API。它是 v1 surface 上獨立的 /openai/v1/embeddings endpoint，跟 Day 5 接的 Responses API 共用 base URL，但是不同的 endpoint（查核 2026-07，embeddings how-to）。

計費也是分開的：embedding 模型有自己的 token 單價，跟 chat 模型的 input/output 單價各算各的（查核 2026-07，定價頁）。

第二，AI Search 的計費型 Dedicated tiers（Basic 以上）按「存在時間」計費，不是按查詢量：Search Unit × 小時，服務建著就在燒錢（查核 2026-07，pricing tiers）。

例外有兩個：Free tier 是共享限額的 $0（一個訂閱只能有一個，功能受限）；新的 Serverless Developer tier 走消費計價、japaneast 有，但它是 preview（且 preview 期間暫緩出帳），不進本系列的 GA 主線。

「建著就燒錢」對本系列的 US$20 上限是直接威脅，所以 Part 3 的 AI Search 一律 ephemeral：建立→測試→截圖→刪除，Day 13 的 script 會把 teardown 做成一等公民。就算實測落在 free tier，這條紀律也照走。

還有一個要先交代的取捨。2026 年的 Azure AI Search 文件會告訴你有兩條 RAG 路線：agentic retrieval（LLM 自己規劃查詢、拆子查詢平行執行）與 classic RAG pattern（hybrid search + semantic ranking，GA）。

而且官方建議新專案從 agentic 開始（查核 2026-07，RAG overview）。那我們要跟嗎？

先把 agentic 的生命週期講精確，因為它不是一句 preview 就能打發：2026-04-01 REST API 已經把一部分 GA 了，包括 knowledge base、knowledge retrieval 與若干 knowledge source 型別。

但這條路線的招牌能力（LLM query planning、answer synthesis、多輪 messages）仍在 preview，portal 的完整功能面也是 preview（查核 2026-07，agentic retrieval overview；GA/preview 逐項清單見官方 migration guide）。

本系列選 classic RAG，理由三個：

• 我們真正想要的那組能力（LLM 規劃子查詢）還在 preview。本系列不把 preview 寫進主線，讀者三個月後照做要能動；只用 GA 的 minimal/extractive 面，agentic 的賣點就剩不多了。
• query pipeline 每一步可解釋、可單獨除錯，這是教學 repo 的存在理由。
• 每多一步 LLM reasoning 都在加 latency 與 token。

順帶排雷：常被引用的「standard ~2–3 秒 vs agentic ~8–15 秒」出自 Architecture Center 一個應用層 agentic RAG範例（3–5 次 tool call），不是 AI Search agentic retrieval 服務的 benchmark（查核 2026-07，agentic RAG pattern）。

量級訊息可以參考，別當成該服務的延遲承諾。

「應用層 agentic RAG」（把 retrieval 當成 agent 的一個 tool）跟 AI Search 的 agentic retrieval 是兩件事。前者等 Day 16 進到 Agent 再回頭看。

Production 注意事項（先立牌子，後面各篇兌現）

• Retrieval 品質要可量測，不然壞了你不會知道。Microsoft 的評估框架把它拆成 process evaluation（檢索那一步好不好）與 system evaluation（最終回答好不好），本系列 Day 28 與 Bonus 會回來。
• Context 不是越多越好。塞太多無關 chunk 會把真資訊淹掉（OpenAI 明列為 retrieval failure 的一種），而且每個 chunk 都是 token。Day 9 的 conversation budget 在 RAG 上會被 retrieval context 吃得更快，Day 14 實作時要把這筆帳算進去。
• RAG 引入新的攻擊面。你檢索回來的文件內容會進 prompt。如果 corpus 裡有人塞了惡意指令呢？這是 prompt injection 的 RAG 變體，Day 21 的主題，今天先知道這扇門從 indexing pipeline 就開著。

今天的成果

day-11 tag（docs 里程碑）：

• docs/rag-overview.md：本篇的兩條 pipeline 分解、Azure 服務對應、classic vs agentic 的選擇記錄
• docs/diagrams/rag-two-pipelines.md：上面那張架構圖的英文對應版（語意同構；本文的中文 PNG 由文章素材目錄的 Mermaid 原始檔產生）

下一篇動工 indexing pipeline 的第一段：文件怎麼切、embedding 怎麼算、index schema 怎麼設計。Day 12 會證明「chunk size 是個 API 合約決策，不是超參數」。

用到的 Azure 服務：本篇為概念篇，未建立任何計費資源（Azure AI Search 於 Day 13 以 ephemeral session 建立）。

本文由作者規劃與撰寫，AI（Claude）協助草稿整理與程式碼驗證；技術內容與觀點由作者確認並負責。